Simulator for simulating an intelligent network

ABSTRACT

A simulator for simulating the performance of an intelligent is described. The simulator includes. 
     a module for simulating any IN-typical event sequences (traffic simulator) according to the rules of traffic theory, and 
     a module for the event-oriented simulation of the service control point (SCP simulator) using process models, The simulator also includes. 
     an arrangement for exchanging data between the modules; 
     an arrangement entering and storing the network configuration, communication service specification, and other simulation parameters, and for transferring them to the correct modules; 
     and an arrangement outputting and/or storing the simulated data. 
     Modules are also provided for simulating the SS7 signaling system, taking into account the functionalities of service relay points SRP and overload protection mechanisms within the IN. The simulation modules communicate in a file mode using transfer files or are linked in an online mode by a shared organization program: the online simulator. Event calendars in which events to be processed by the simulation modules are entered in their processing order and enable the processes running parallel in a real situation to be converted to sequentially executed processes are central elements of the simulator in online mode. The IN simulator can determine the performance of an IN in a present and a future configuration, thereby locating weak points and increasing IN efficiency.

FIELD OF THE INVENTION

The present invention relates to a simulator for simulating anintelligent network, in particular for locating and analyzing weakpoints, testing network configurations and/or control mechanisms, anddetermining ways to increase the network's performance.

BACKGROUND INFORMATION

All over the world, the term intelligent network (IN) is used todescribe a network architecture that applies to all telecommunicationnetworks. At the heart of this concept is an individual,software-defined communication profile for customers oftelecommunication services. The IN combines important functions and datain a central location and provides them in only one or just a few nodes.These functions and data include, for example, information on how a callwith an IN-specific telephone number is to be handled depending on itsplace of origin, the phone number dialed, the time or day, and/or otherparameters, e.g., whether and to which network subscribers a call is tobe forwarded, whether and to which recorded announcements a call is tobe switched, or whether a call is merely counted. The intelligentnetwork provides an intelligent, distributed database access capabilityfrom a plurality of service switching points (SSPs) to data andfunctions stored in one or just a few service control points (SCPs) forthe purpose of controlling the service.

From an organizational standpoint, the intelligent network is acentralized network above a telephone network and provides theintelligence for setting up and releasing calls conducted over thetelephone network. The interface between the telephone network and theintelligent network is formed by the SSPs, where calls with IN-specifictelephone numbers arrive and, after receiving the processing informationfrom the SCP, are processed according to these instructions, e.g., theyare forwarded to a telephone number provided by the SCP.

The individual function complexes are implemented on separate systemlevels within the intelligent network. IN transport and switchingfunctions are implemented on the service switching point (SSP) level,service control and service data management functions on the servicecontrol point (SCP) level, and service management functions in theservice management system (SMS). The SSP and SCP levels communicate viathe signaling system No. 7 (SS7) over which IN-specific messages aresent for call handling purposes. Signaling transfer and control withinthe SS7 system are handled by one or more service transfer or servicerelay points (STP and SRP). The STP or SRP is used to switch anddistribute (route) messages on the central signaling channel between theSCP and SSP. The STP or SRP can also serve as a gateway for messagesthat affect the IN services of a different carrier and must be processedby the SCP in a different IN. An important routing criterion of an INmessage is its global title; the STP/SRP level carries out the globaltitle translation (GTT) function.

The SSP level has mechanisms for detecting IN calls, e.g., based on thetelephone number, and for supporting these calls. In the case of thesecalls, an SCP has to be interrogated to obtain information needed tocontinue setting up the call. The SCP contains programs andcorresponding data for controlling the services. In addition, the SCPcollects data for billing purposes and statistical analyses. MultipleSSPs access one central SCP. The SCP is subordinate to the servicemanagement system, which administers the IN services and IN components.

An intelligent network can be used to implement the following INservices, among other things:

Televoting (televotum) (TV): the televoting service enables the servicesubscriber to record the number of calls placed to is televoting number.According to one version of this service, the SCP is interrogated eachtime a call is made, while in another version the calls are pre-countedin the SSP, with the SCP being interrogated only after k number of callshave been processed. Regardless of the version selected, each TV callarriving in the IN system is recorded. In addition, each nth call can behandled in a special way depending on the active traffic routingprogram, e.g., forwarded to a destination address defined by the servicesubscriber after being recorded. All other calls are transferred, afterbeing recorded, to a recorded announcement which was also defined in theservice subscriber's traffic routing program.

Freephone (FPH): the freephone service allows service users to place atoll-free call to the “service subscriber”. The service subscriber paysall charges.

Universal number (UNU): the universal telephone number service enablescallers to reach a service subscriber under a standard, localnetwork-independent telephone number regardless of his present location.The charges for calls of this type may be assigned to the caller only orshared between the calling and called parties, depending on the optionselected by the service subscriber.

Tele-info service (TIS): the tele-info service gives callers access to arange of information provided by the service subscriber by dialing thelatter's recorded announcement equipment or through direct dialog. Thecharges are billed to the caller and can be shared between the carrierand service subscriber on the basis of the call-specific information.

Other services are also possible, such as assigning a telephone numberto a customer instead of to a line and redirecting all calls made underthis telephone number to the customer's present location. In this sense,mobile radio networks are also intelligent networks.

The service subscriber has the option of specifying his service based onadditional service features, including: Rerouting: if the dialedsubscriber does not answer or the line is busy, the call is eitherswitched to a recorded announcement or another number. This procedurecan be repeated up to a preset number of attempts, after which the callis rejected.

Call limit: if the number of calls to a destination number exceeds thelimit defined by the service subscriber within a certain period of time,the excess calls are routed to defined alternative destination numbersor recorded announcements.

Time-dependent destination control: the time of the call is compared tothe periodic and/or temporary time window. If no valid time window isfound, the SCP transfers the IN call to a standard advisory message;otherwise it branches to the call destination or to the next feature.

Origin-dependent destination control: the network origin information iscompared to the origin information stored in the traffic routingprogram. If no match is found, the SCP transfers the call to a standardadvisory message; otherwise it branches to the call destination or tothe next feature.

Call distribution: the call distribution feature enables users to defineindividual quotas according to which calls are distributed to differentdestinations.

If a call is switched to a recorded announcement, the SSP acts like afictitious communication party. The SSP supports networkservice-specific standard advisory messages and recorded announcementsthat can be controlled as call destinations. The individual recordedannouncements have a limited number of attendant consoles. If allattendant consoles are busy, the excess calls are rejected. Each messageis limited by a maximum playback time and number of repetitions.

For most of the IN services, e.g., FPH, UNU, TIS, and TV without thepre-counting function, the function of the intelligent network is totranslate the dialed IN number to a real number as a function of definedservice parameters in the traffic routing program. This is doneaccording to the following main sequence:

1. The SSP evaluates the first few digits in the dialed telephone numberand detects the IN service. The SSP sends a PROVIDE INSTRUCTION messageto the SCP asking how this call is to be handled. The message containsthe IN subscriber number dialed by the service user (CALLED PARTYADDRESS) and the caller's telephone number (CALLING PARTY ADDRESS) asparameters.

2. In the SCP, the PROVIDE INSTRUCTION message accesses the servicelogic program for the corresponding IN service. The subscriber-specifictraffic routing program addressed by the CALLED PARTY ADDRESS isactivated. In the procedure described here, the result of this is todetermine a destination for setting up the call, which can be either atelephone number or a recorded announcement. In addition, the trafficrouting program can provide requests for monitoring the call, such asmonitoring of “subscriber busy” and “subscriber does not answer”. TheSCP saves the results in a call-specific context and sends theCREATE-JOIN and MONITOR messages to the SSP. The message contains theCALLED PARTY ADDRESS and EVENT LIST, which specifies the events to bemonitored, as parameters.

3. The SSP sets up a call to the B party over the telephone networkusing the destination number transferred in the CREATE-JOIN parameter orswitches the call to a recorded announcement.

4. The SSP monitors the call setup procedure to the B party, if this wasspecified in the EVENT LIST. If the B party does not respond, the callplaced to the B party is released at the and of a timeout, and the SCPis notified of the event via the EVENT message.

5. The traffic routing program defines an alternative (rerouting)destination and sends a CREATE-JOIN and MONITOR message containing theappropriate parameters to the SSP.

6. The SSP sets up a call to the B party over the telephone networkusing the destination number transferred in the CREATE-JOIN parameter orswitches the call to a recorded announcement. When the B party answers,the call is put through.

7. At the end of the call, the SSP collects the call charge andstatistic data needed in the SCP and transfers it in the EVENT(CALL END)message. In the SSP, a timer monitors confirmation of this message bythe SCP. If no confirmation arrives before the timer expires, theEVENT(CALL END) message is sent again.

8. After receiving the EVENT(CALL END) message, the SCP sends a messageto end the TCAP dialog. The SCP reactivates the call-specific context.The received time stamps are saved along with the data stored in thecontext (call tickets). They are transferred to the SMS later on forfurther processing. Counters maintained in the SCP (e.g., for successfulcall attempts) are incremented (counter tickets).

Points 4, 5, and 6 of this sequence occur only when a call is rerouted.

To ensure that the IN continues to operate properly even with a hightraffic volume, overload protection mechanisms are provided in the IN.The overload protection mechanism causes the SSP to reject IN callswithout first interrogating the SCP according to certain criteria.Examples of overload protection mechanisms include AUTOMATIC CALLGAPPING (ACG) and the LEAKY BUCKET method. Overload protection can bebased on services and/or destinations.

A service control point is usually a multi-layer system with a hardwarebase and multiple software layers (usually three). The hardware baseincludes a computer with one or more parallel processors as well astrunks, hard disks, magnetic tapes, terminals, and printers. The firstsoftware layer contains the system software. The second software layer(NODE software) contains general functions for the service application.The third software layer provides the application that supports thecall-processing services. If the SCP has a parallel-processingarchitecture, it includes a plurality of processors, each of which formsa self-contained unit with a CPU, main memory, power supply unit, andinput/output processor and is connected to the others by a bus system.

The various SCP software layers include operating system processes andgeneral processes that do not belong directly to the operating system,such as those for communication between the processes or for efficientlocal cache management, as well as application processes which areneeded for processing an IN message. An IN message arriving at the SCPthus passes through a sequence of processes in various SCP layers,resulting in the generation of an IN message sent by the SCP to the SSPin response to the SSP's request for call handling instructions. Theprocesses can be service- and/or service subscriber-dependent or theycan be used independently of the service or subscriber in all INmessages. The processes are implemented in one or more incarnations onall or only selected processors in an SCP.

An IN message is generally processed by the SCP according to thefollowing scheme, implemented by calling up a preset chain of individualprocesses:

A message from the SSP is received and forwarded to the SCP computer.The SCP computer receives the messages, provides storage space, andchecks the message to determine its validity range. The call handlingcontext is drawn up. A routing tree is loaded from the working memory orfrom the hard disk. The telephone number to be dialed is selected fromthe routing tree. The context to place the call is stored and a reply tothe SSP is prepared. The reply is sent to the SSP in the form of a newIN message.

All processes needed to process an IN call are activated on only oneprocessor, and the preceding process must be terminated before the nextprocess can begin.

The end-of-call handling after the caller has released the call from theexchange to the SPP is processed in the same manner as the call setuphandling described above using a corresponding process chain.

An IN message in the STP/SRP is also processed by processing apredetermined chain of consecutive processes.

Long average processing times have been observed during measurementsconducted in existing IN networks, in particular on their centralcomponent (the SCP). This leads to unacceptably long call setup timeswhen the system is heavily loaded by IN traffic, in particular duringpeak hours involving the televoting service, but also as a result ofother influences. However, it is difficult to analyze weak points in theIN network which could lead to such long response times, since themeasured values are merely statistical data and a measurement cannot beconducted during each stage of message processing. In addition,conducting measurements in real INs poses a fundamental problem in thatall real detailed measurements influence the performance of the systemto be investigated by activating additional measurement processes thatare not part of the regular IN call handling functions.

A further problem arises when implementing new components in an existingIN. The IN is in operation at each point in time, making it impossibleto change parameters in this complex system without jeopardizingoperating reliability. It is also not presently possible to determinewhether, for example, processors having a certain technicalspecification actually achieve the performance levels promised by themanufacturer.

In addition to the need to analyze weak points in existing intelligentnetworks, there is also a need to test as yet unimplemented networkconfigurations as early as the planning stage so as to determine theconfiguration that has the best performance under given basicconditions. For example, the question arises as to how powerful the SCPor its individual processors must be or what capacities must beprovided, and possibly in what form, for the individual services. Thequestion also arises as to whether and how better performance can beachieved, possibly by changing the process management functions withinthe IN processors. A further critical element in operating anintelligent network is the overload protection mechanism which issupposed to stabilize the system as closely as possible to itsperformance limit. In practice, corresponding overload protectionparameters can be determined only with great difficulty, which meansthere is a need to determine the optimum overload protection settings asa function of other network configurations and independently of networkoperation and to transfer them to the real network.

SUMMARY

An object of the present invention is therefore to provide a tool formeasuring the performance of a communication network with an INstructure. In doing this, the user should be able to set and change awide range of network configurations and call handling methods withinthe network components, i.e., the simulation must be independent of theselected IN platform. Statistical data on network performance must begenerated which can be compared to data measured by real IN components;however, data which cannot be accessed in real networks should also beprovided, for example call-specific logging of the processing times asthe call passes through the intelligent network.

This object is achieved according to the present invention with asimulator for simulating the performance of an intelligent network (IN)having the following components:

1. a module for simulating any IN-typical event sequences (trafficsimulator) according to the rules of traffic theory;

2. a module for the event-oriented simulation of the service controlpoint (SCP simulator) using process models;

3. means for exchanging data between the modules;

4. means for entering and storing the network configuration,communication service specification, and other simulation parameters,and for transferring them to the correct modules;

5. means for outputting and/or storing the simulated data.

Because the reasons for the performance shortcomings in the intelligentnetwork can frequently be found in the central SCP, due to the network'scentralized structure, the SCP model forms the heart of the simulator.Queue modules and process models make it possible to create a detailedmodel of the SCP software structure. A further module, the trafficsimulator, is needed in the IN simulator to generate an IN-specific loadand to produce realistic input for the SCP simulator.

The simulator is implemented at the core by a computer program. Atstartup, or during simulation, this program accesses files in which arestored parameters for configuring the network or the network components,for specifying the communication services, i.e., the type and sequenceof call handling functions, and other parameters that affect thesimulation run, such as information about the traffic volume. The usercan write and change these files in the usual manner. The simulationparameters are preferably entered using a computer monitor and keyboard.The simulation parameters are stored and can be modified individually orin their entirety prior to running a new simulation, making it possibleto selectively analyze the influence of individual parameters on thesimulated IN performance.

The simulation method used is an event-controlled simulation.IN-specific events, which pass through the individual simulatorcomponents for processing, are generated at specific points in time. Theprocessing times that arise in the individual simulation modules, andpossibly also in subcomponents of the simulation modules, are alsologged. In addition to the basic components of SCP simulator and trafficsimulator, the IN simulator preferably also has a module for theevent-oriented simulation of the signaling system No. 7. This SS7simulator operates on the basis of queue models to the extent thatfunctionalities in the SS7-integrated processors are to be simulated,and/or provides a message with only one constant delay time that takesinto account the finite runtime on the signaling channels between theSSP and the SCP. The components to be simulated by the SS7 simulator arethe processors/process chains on the SSP level, the STP/SRP level, and,depending on the network configuration, the SCP level, e.g., an SCPinput processor (FRONT-END SYSTEM) which forms the interface between theSCP and the signaling system.

In a further advantageous embodiment of the present invention, a modulefor simulating overload protection mechanisms is provided. This overloadprotection simulator modifies the number of events processed by at leastone of the other simulation modules as a function of the load on one ormore simulation modules, e.g., as a function of the queue length, and/oras a function of user-definable parameters. The user-definableparameters can include, for example, load tolerance limits which, whenexceeded, activate the overload protection mechanism. Instead ofpermanently defined limits, a “fuzzy” determination can also beprovided, e.g., using fuzzy logic. An overload protection simulator thatreceives its control parameters from the SCP simulator, accesses thetraffic simulator, and regulates the number of IN events generated orforwarded by the traffic simulator as a function of the controlparameters comes closest to simulating real events. After manipulatingthe overload protection mechanism, there is a certain probability that acall which was first generated by the traffic simulator will not betransformed into an IN event corresponding to a request from the SSP tothe SCP, and is therefore not passed on to the other simulation modules.In reality, this is a call that is rejected by the SSP.

The overload protection simulator advantageously simulates the AutomaticCall Gapping (ACG) mechanism. In this case, all calls or eventsexceeding a certain number are rejected within a certain interval.

The traffic simulator, SCP simulator, and possibly the SS7 simulator andoverload protection simulator modules are separate simulators of thecorresponding network components. Internally, their functions are eitherlinked by files (file mode) or preferably integrated by an organizationprogram (online mode) which processes the individual IN events acrossall components of the IN simulator.

In file mode, the simulation modules communicate with each other byperforming read and write access to files in which the data relating tothe network configuration or network components to be simulated, andpossibly the data generated by one of the simulation modules, is stored.

To carry out a full network simulation, the partial simulations areinvoked consecutively. A simulation run begins when the trafficsimulator generates the traffic volume in the IN. The generated messages(PROVIDE INSTRUCTION, with its generation time t1, EVENT or CALL END)are stored in a first transfer file and read in by the simulationmodule, which is subsequently invoked. A call identification number,which enables multiple messages to be assigned to the same call andthus, in the end, to determine call-specific response times, is alsostored for each message. In the simplest simulator version, this secondsimulation module is the SCP simulator. Taking the SS7 into account, thefirst file is then transferred to the SS7 simulator. In this case, SS7output time t2 is added to the messages after the latter pass throughthe SS7 simulator, and the messages are written to a second transferfile that is accessed by the SCP simulator. The SCP simulator generatesa CREATE-JOIN or CALL END message for each of the entries present in thefile transferred to the simulator and writes the message, together withoutput time t3, to a third file. Before the message arrives at the SSP,the SS7 simulator is run once again, logging SS7 output time t4.

By determining the difference between the logged time stamps, the delaytimes in the individual network components and in the overall networkcan be derived from the transfer files of the simulation modules.

Because the sequential operation of the partial simulations prevents anysort of feedback loop between the network components, the proceduredescribed above is carried out multiple times to reach a steady stateand largely simulate the functionalities of the real network.

File mode is highly suitable for studying the behavior of individualnetwork components separately from the network, i.e., without feedback.The behavior of the individual components can be determined quickly anddirectly, for example by modifying the corresponding simulationparameters. The individual IN components can be modified and analyzedseparately. File mode also enables all individual EVENTS between thecomponents to be easily tracked. Due to the stationary behavior of theoverall system, however, file mode allows only iterative determinationsto be made, based on suitable initial conditions.

In online mode, an organization program ensures that the partialsimulations run more or less in parallel. The simulator is thus able tosimulate the network as a whole and, in particular, to take into accountfeedback between the components directly. Event calendars are used toconvert the message processing operations in the network components,which run parallel in a real network, to sequential or quasi-parallelprocessing operations of the IN events in the simulation modules. Anevent calendar is a list of all events that are to be processed by oneelement, e.g., the simulator, a simulation module, or a sub-component ofa module, e.g., IN messages or individual processes that are entered inthis list in chronological order. The event calendar enables the onlinesimulator to specify which event will be processed next (event-orientedsimulation). The time at which the next event starts is derivedadditively from the starting time and duration of the preceding event.The global event calendar, which contains the events to be processed byall the simulation modules as a whole in chronological order, plays acentral role in operating the simulation modules in quasi-parallel mode.On the basis of the global event calendar, the simulator specifies whichpartial simulation is to be invoked at which simulation time. Inaddition to the global event calendar, there are also local eventcalendars that are managed by the simulation modules. Events in thefollowing event groups are entered in the global event calendar:

Internal events: internal events are references to the local calendarsin the corresponding simulation modules. They affect how a simulationmodule progresses to the next simulation step.

External events: external events are the input of an IN message in apartial simulation; they represent messages that are exchanged betweenthe simulation components and are used for communication between thesimulation components.

Call-independent events: according to one embodiment of the presentinvention, events that are independent of the IN events and belong, forexample, to the simulation of the operating systems in thesub-components, are also entered in the global calendar.

All events generally cause the respective simulation modules to generatea follow-up event which, in turn, is entered in the global eventcalendar and, in some circumstances, in the local event calendars aswell. Some events, after being processed, trigger a logging operation onthe basis of which the speed at which a message was processed by thecorresponding simulation module can be determined.

The user can preferably access the functions of the IN simulator via auser interface. This interface administers one or more simulations byproviding input screens for entering the simulation parameters of theindividual simulation modules, stores the entered data in correspondingfiles, and saves it according to simulation. The user can generate a newsimulation by copying and modifying selected parameters. The userinterface includes a largely independent file management system for thesystem of configuration and event files belonging to each simulation.The user can display all simulated data. The “measured quantities”selected by the user, e.g., SCP utilization, queue length in the SCP,traffic volume in the IN, are prepared with the help of a graphicprogram and can be displayed in graphic form on a computer screen. Thesimulation results of one simulation as well as different simulationscan advantageously be displayed together on the same screen. Inaddition, file filters can advantageously be used to generate outputfiles for further processing the data in other programs.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the topology of an intelligent network.

FIGS. 2 and 3 show the structure of a simulator according to the presentinvention, operating in file mode.

FIG. 4 shows the structure of a simulator according to the presentinvention that can operate in file or online mode.

FIG. 5 shows a block diagram of an IN simulator.

FIG. 6 shows one example of configuration parameters for the trafficsimulator.

FIG. 7 shows a flowchart of simulator operation in file mode.

FIG. 8 shows a flowchart of simulator operation in online mode.

FIG. 9 shows a schematic representation of the processing of a globalinternal event from the perspective of online simulations.

FIG. 10 shows a block diagram of the SCP simulation.

FIG. 11 shows an example of configuration parameters for the SCPsimulator.

FIGS. 12, 13 show the process management model of a CPU on which the SCPsimulation is based.

FIG. 14 shows a schematic, object-oriented model of an SCP simulator.

FIG. 15 shows an arrangement of the SS7 layers.

FIG. 16 shows a model of the MTP3 level of the SRP.

FIG. 17 shows a model of the TCAP layer of the SS7.

FIG. 18 shows an example of configuration parameters for the SS7simulator.

FIG. 19 shows the implementation of the overload protection simulator inthe IN simulator in online mode.

FIG. 20 shows the implementation of the overload protection simulator inthe IN simulator in file mode.

FIGS. 21, 22, 23 show examples of simulation data obtained with the INsimulator.

DETAILED DESCRIPTION

FIG. 1 shows the topology of an intelligent network to illustrate thesimulation concept. An intelligent network has three main logicalcomponents: a service control point (SCP) 109, a service switching point(SSP) 102, and a signal transfer point or signal relay point (STP orSRP) 103. The SSP level accepts signaling requests from the externalcustomer devices via one of exchanges 101 in the telephone network andoperates the call setup procedure for IN-specific connections of thistype.

The SCP level includes procedures and databases for call evaluation andcall management. This information is used to select a route for a callthrough the telephone network. The SCP or SRP performs switchingfunctions between SCPs and SSPs. The SSP, SCP and STP/SRP componentscommunicate with each other via the signaling system No. 7 (SS7). Aplurality of signaling channels 106, 107, 108 usually exists betweenSTP/SRP and SSP or STP for this purpose.

In principle, three logical components, SSP, SCP, and STP/SRP, can beintegrated into one physical device, e.g., into an exchange. However,the pyramid structure of the intelligent network illustrated in FIG. 1,having a central SCP 109, a plurality of remote SSPs 102, and a fewSTPs/SRPs 103, which form the message nodes in the SS7 system, is usual.Physical B channels 105, over which telephone calls can be set up, existbetween the exchanges in the telephone network and the SSPs. Generally,a call with an IN-specific telephone number is first switched to an SSP,which, after receiving the processing information from the SCP, forwardsthe call to its destination. The SSP thus forms the interface betweenthe telephone network and the intelligent network. SSP functionalitiescan also be integrated directly into an exchange.

During the IN simulation, the traffic simulator simulates the IN traffictransferred from the SSPs to the intelligent network, the-SCP simulatormodels the function of the SCP, and the SS7 simulator models thefunctions of the SSPs, STPs/SRPs, SCP input processors 104, and thetrunks between these components. By making entries related to thenetwork configuration, the simulator user can select any networktopology, thus adjusting the structure of the simulated network to anyrequirements. The user-definable simulation parameters include thenumber of SSPs 102, the number of STPs/SRPs 103, the number of SCP inputprocessors 104, the number of signaling channels between an STP/SRP andan SCP or an SSP, and possibly also the number of SCPs.

FIG. 2 shows the structure of an IN simulator according to the presentinvention and operating in file mode, including traffic simulator 201and SCP simulator 202 modules. Depending on the user settings, which arestored in input files 208, 209, 210, 211, 212, traffic simulator 201generates an IN-specific traffic volume, i.e., a sequence of eventsrepresenting IN messages sent from one or more SSPs to the SCP, takinginto account any data stored in transfer file 204. The user canpreferably access input files 208 through 212 from a common userinterface, and the files are read in by traffic simulator 201 at thestart of the simulation. Input fields 208 through 212 contain parametersthat each affect different aspects of the simulation, e.g., the networkconfiguration in the area of the interface between the IN and telephonenetwork (number of SSPs), the internal settings of an SSP (number ofattendant consoles per service, time remaining to timeout, number oftrunks), probabilities relating to the further progress of a call(average call and/or recorded announcement duration, maximum recordedannouncement duration, rerouting probability), information on theaverage number of calls per time unit and service for one or moreconsecutive intervals. The fact that the number of input files 208through 212 is random and, for example, all user input affecting othersimulation modules can be stored in any number of files, including asingle file, is self-evident.

In the example illustrated here, SCP simulator 202 has one SCP inputfile 207 in which user input relating to the SCP configuration is storedand which SCP simulator 202 reads in at the start of the simulation.

In file mode, traffic simulator module 201 and SCP simulator module 202are activated consecutively. The sequence of events generated by thetraffic simulator is written to a first transfer file 203, whichcontains the event sequences that are now to be processed by SCPsimulator 202. In the next step, the SCP simulator reads in thistransfer file 203 and processes the events stored therein. SCP simulator202 enters the processed events in a second transfer file 204. Thelatter is returned to traffic simulator 201 during the simulation, butcan also be provided directly to the evaluator, as can first transferfile 203.

The transfer files provide the contents of the event calendars of theparticular receiving module. In transfer files 203, 204 are stored thedata generated by traffic simulator 201 or SCP simulator 202 in the formof a data record which contains at least one time stamp indicating thetime at which the corresponding message was generated in the trafficsimulator or the SCP simulator as well as an identification number thatallows two or more messages to be assigned to the same call. Thedifference between the two time stamps yields the time it takes for amessage to be processed in the SCP. The simulator illustrated in FIG. 2can thus be used to directly simulate the response of the SCP to a giventraffic volume. This representation does not include signaling systemNo. 7.

Simulation modules 201, 202 also store statistical data in output files205, 206, including data relating to processor utilization in the SCP,the queue length in the SCP, or trunk utilization to and from the SSP.The data recorded in these files is also available for furtherevaluation of the simulation results.

FIG. 3 shows the structure of a simulator according to the presentinvention and operating in file mode, including traffic simulator module301, SS7 simulator module 303, and SCP simulator module 302. Compared tothe simulator illustrated in FIG. 2, only SS7 simulator module 303 hasbeen added to the simulator in FIG. 3. As a result, four transfer files304, 305, 306, 307 are now exchanged between the modules duringsequential processing of the partial simulations.

As described in the example above, the simulation of the intelligentnetwork begins by generating an IN-specific traffic volume. To do this,traffic simulator 301 reads in input files 312 through 316, whichcorrespond to files 208 through 212 in FIG. 2; transfer file 307, ifprovided, is also read in. The event sequence generated by trafficsimulator 301 is stored in first transfer file 304. SS7 simulator 303 isinvoked next. This simulator first reads in SS7 input file 317, in whichis stored, for example, data relating to the configuration of the SS7system. SS7 simulator 303 stores the event sequences it has processed ina second transfer file 305, which is read in by SCP simulator 302 afterthe latter has been invoked. The event sequences processed by SCPsimulator 302 are then entered in a transfer file 306. To simulate thereturn of the IN messages from the SCP to the SSP, SS7 simulator 303 isreactivated and processes the event sequences stored in third transferfile 306, storing the results in fourth transfer file 307. If necessary,traffic simulator 301 is reactivated and the cycle from SS7 simulator toSCP simulator and back to SS7 simulator is repeated to simulate feedbackloops between the network components. This iteration is repeated untilthe changes to the traffic data in one or more transfer files 304through 307 (or 203, 204 above) have exceeded a limit that is acceptableto the user, thus bringing the system to the steady state.

Statistic data relating to individual simulation modules 301, 302, 303is written to output files 309, 308, and 310. This data relates, forexample, to SRP processor utilization or the number of lines occupiedbetween the SRP and SCP or the SSPs during the SS7 simulation.

The data stored in the transfer files includes call-specific datarecords, each of which contains at least one time stamp. This time stampis derived from the instantaneous simulation time when generating orprocessing the corresponding message in the various simulation modules.The processing times in each of the simulated network components canthus be calculated by determining the differences.

FIG. 4 shows the structure of a simulator according to the presentinvention that can be operated in both file and online modes. Thesimulator has the simulation modules already described and illustratedin FIG. 3: traffic simulator 401, SS7 simulator 403, and SCP simulator402. As described above, these components communicate via transfer files406, 407, 408, 409.

Compared to the simulator illustrated in FIG. 3, the simulator shownhere has one additional module, an overload protection simulator 404.This simulator regulates the event sequences generated or forwarded bytraffic simulator 401 as a function of specific user-defined parameters,stored in file 424, and as a function of the load on the remainingsimulation modules.

Simulation modules 401, 402, 403, and 404 are linked by a commonorganization program: online simulator 405. A user interface 410 is alsoprovided which is connected directly to all components, i.e., thesimulation modules, in one or both directions. Indirect connections alsoexist between the user interface and the simulation modules via files411 through 414 (input files for traffic simulator 401), 415 (SS7 inputfile), 416, and 423 (SCP input/output file), 417 through 420 (outputfiles for online simulator 405), which can be used to configure themodules and to output collected system data. As in FIGS. 2 and 3, thebroken arrows in FIG. 4 represent file operations, while the solidarrows show a direct form of communication, e.g., a link formed by acommon organization program. An arrow begins at the component whichtransfers parameters or messages to another simulation component.

The simulator illustrated in FIG. 4 can operate in file mode by invokingthe individual simulation modules sequentially, as well as in onlinemode, in which case the simulation modules operate more or less inparallel.

The user interface is always linked to the traffic, SS7 and SCPsimulators; each simulation is started from the user interface bytransferring the respective simulation parameters. In file mode,subsystems are executed as independent programs after being invoked,i.e., independently of the user interface and without any interaction.

The bi-directional link between user interface 410 and online simulator405 allows the simulator to be started by transferring the respectiveparameters and also enables “measured data” to be returned for output ingraphic form during runtime (online mode). The user can also temporarilyinterrupt the simulation run or terminate it prematurely.

Simulation modules 401, 402, 403, and 404 are integrated by aprogramming system into online simulator 405, which controls thequasi-parallel execution of partial simulations by sending and receivingmessages that are administered in the global event calendar. In onlinemode, therefore, all communication processes between traffic simulatormodule 401, SS7 simulator module 403, and SCP simulator module 402 takeplace via online simulator 405. Transfer files 406 through 409 are notused directly in online mode. However, they are used indirectly in thelocal event calendars.

Online simulator 405 initiates the entry of presettable loggingquantities in log files 417, 418, 419, 420, e.g., time stamps t1 throught4 described above, SCP utilization, data relating to networkutilization or the number of occupied lines. The data stored in thesefiles can be output and viewed on the user interface in the knownmanner.

Because the overload protection mechanism regulates the traffic arrivingin the IN via feedback loops, it is useful in most cases to simulateoverload protection mechanisms only in online mode. In the simulatorillustrated in FIG. 4, overload protection module 404 therefore does nothave a direct link to SCP simulator 402, on the basis of whose loadoverload protection simulator 404 regulates the number of eventsgenerated by traffic simulator 401. SCP simulator 402 and overloadprotection simulator 404 are linked indirectly via online simulator 405only in online mode.

FIG. 5 shows a block diagram of an IN simulation from the user'sperspective. The simulation modules themselves are not shown, but ratherare processed within black box 501. Overload protection simulator 502and/or SS7 simulator 503 can each be activated or deactivated, with thisaction being represented by switches in FIG. 5. The user can also choosebetween file and online mode, with this action also being represented bya switch.

In addition to these settings, which relate to the simulator structure,the user can also define, after starting the simulator, the actualsimulation parameters, i.e., the network configuration to be simulated,the traffic volume, etc. If bootstrapping is performed, the simulationmodules re-read in all input files. However, it is also possible toselectively change individual parameters for generating a new simulationand to repeat passes of an earlier simulation. Based on predetermined orretrieved simulation parameters, simulator 501 then determines thepreset output data, such as traffic, CPU utilization, queue length, as afunction of the simulation time, and writes these parameters to files.The data can then be displayed on the screen or stored on data media andsupplied to a further processing system.

FIG. 6 shows an example of configuration parameters for the trafficsimulator as well as examples of numeric values for these parameters.The parameters listed in the table in FIG. 6 can be subdivided intoservice-specific parameters, which can be set separately for allservices to be simulated, televoting parameters, which relate to thetelevoting service, and general parameters that apply to all services,i.e., to all calls generated by the traffic generator. Theservice-specific parameters can be set for the following IN services:freephone (FPH), tele-info service (TIS), universal number (UNU),IN-service FPHL, and televoting (TVS). Some of the parameters that canbe set for the other services are not useful for the televoting service;these parameters are therefore marked with an X in the correspondingcolumn. Ordinary telephone traffic (NVK) can also be included, sincenon-IN-specific calls also load the SSP in certain networkconfigurations and can therefore contribute to IN utilization. The firstservice specific parameter (average call duration) is the onlyreasonable setting for NVK, since the remaining parameters relate to INfunctions such as switching a call to a recorded announcement orrerouting a call.

The service-specific parameters include the average call duration,average recorded announcement duration, maximum recorded announcementduration, number of attendant consoles for recorded announcements andrerouting probability as well as for rerouting probability due to“subscriber busy”. These parameters are needed to determine theprobability of a follow-up event being generated at each simulationtime, i.e., the probability of an EVENT or EVENT(CALL END) message beinggenerated.

The televoting parameters can be entered separately for each televotingservice subscriber TV1, TV2, etc. Only two service subscribers areactive in the example shown here. The programmable parameters are: SSP1or SSP2, number of destination values to connection, start time, stoptime, and stop time for follow-up calls. The “destination value”parameter indicates the number of televoting calls that must be receivedby the specified SSP to generate a message for the SCP. If thisparameter is set to 1, the televoting without precounting option is set;if the value is greater than 1, televoting with precounting in the SSPis set. The subsequent “number of destination values to connection”parameter indicates whether and after how many calls a connection is setup to the service subscriber. Because the televoting service is usuallyprovided within strict time limits, the service start and stop times arealso specified. The “stop time for follow-up calls” parameter indicatesthe time at which late TV calls are rerouted to an informative, possiblyservice subscriber-specific recorded announcement. The televotingparameters indicate the conditions under which a TV call generated bythe traffic generator produces a first IN event.

The following general configuration parameters can also be set: The“time until timeout” parameter indicates how long the system must waitbetween transmission of an IN message to the SCP and failure to replyfrom the SCP before the SSP rejects the call. The “rerouting time delay”parameter indicates how long the system waits before rerouting a call.The “average and maximum recorded announcement duration for “TVinactive” parameter and the “number of attendant consoles” parameter forthis recorded announcement specify how to handle incoming TV calls thatarrive during times when the televoting service is inactive. The “numberof lines to and from the SSPs” parameters relate to the networkconfiguration in the area between the exchange and the SSP. The numberof lines for the freephone service can also be specified. The “averagewaiting time for the A party” parameter indicates the average timeinterval after which the calling party hangs up if a call has not yetbeen set up. The following two parameters indicate the probability withwhich a follow-up call will be generated in the case of an unsuccessfulcall attempt and the maximum number of follow-up calls that aregenerated.

To generate an IN-specific combined traffic volume, not only are theparameters described above needed, which relate primarily to thegeneration of IN follow-up events (EVENT message), but also otherparameters that define the basic conditions for generating correspondingIN initial events (PROVIDE INSTRUCTION). A step for entering the averagetraffic volume in terms of the number of calls per time unit istherefore provided. The average traffic volume can be changed at anyuser-defined points in time, remaining constant between these times.This makes it possible to generate time-dependent load curves of anyshape, in particular peaks that are typical for the televoting servicewhen services are properly assigned. The average traffic volume isentered for each IN service (FPH, TIS, UNU, FPHL, TV1, . . . , TVn) andfor ordinary telephone traffic (NVK). If multiple SSPs are provided, thetraffic volume is entered separately for each SSP, depending on theservice. The number of SSPs is thus also a parameter that can be set forthe traffic simulation.

A step-by-step variation over time is assumed for the traffic volume,with each step or each time interval preferably having the same timelength. The number of intervals and the length of the intervals can bespecified.

According to the rules of traffic theory, the probability of a call witha special service ID or service subscriber ID arriving at an SSP isdetermined for each simulation time or each simulation interval based onthe above settings. The length of the simulation intervals is preferablymuch shorter than the length of the intervals for which the userspecified an average traffic volume. The length of the simulationintervals preferably lies in the nanosecond range, while the trafficvolume varies on a time scale of seconds, e.g., 10 to 100 seconds. Thelength of the simulation interval is preferably selected so that a totalof one call is generated per interval, thus making it possible to listall generated calls in chronological order.

The instantaneous probability in each case is calculated, assuming agiven probability distribution and the specified instantaneous averagetraffic volume for the service being handled, service subscriber or SSP.The probability distribution used is preferably a Poisson distribution,since this method describes the statistical occurrence of independentevents and therefore best reflects the statistical fluctuations intelephone traffic. A time sequence of events is therefore generated foreach service, service subscriber, and/or SSP, with the number of callsper time unit fluctuating statistically by the predeterminedinstantaneous average value. In the case of the FPH, TIS, UNU, FPHL, andtelevoting without precounting services, each generated call potentiallybecomes an IN-specific event that contributes to the utilization of theintelligent network and therefore is relevant for simulating theperformance of the IN, and the SCP in particular.

According to the PROVIDE INSTRUCTION IN messages, the first eventsgenerated in this manner are entered in the first transfer file in theglobal event calendar and in file mode, along with their generation timet1, in chronological order. If the precounting function is active,televoting calls generate a first IN event only after each nth call(PROVIDE INSTRUCTION). This event is also added to the global eventcalendar or to the transfer file, along with generation time t1. Theremaining calls as well as ordinary telephone calls lace a load only onthe SSP, but do not cause IN events to be generated.

The traffic generator also generates follow-up events assigned to an INcall or a first event, taking into account the probabilities entered inthe configuration file which relate to the further progress of an INevent. For example, if the IN call is properly put through to a realsubscriber or is switched to an attendant console based on the callhandling information (CREATE-JOIN) from the SCP during the simulation,the call is terminated at the end of the specified average call orrecorded announcement duration in that the traffic generator generatesthe EVENT(CALL END) follow-up event and enters it in the transfer fileor in the global event calendar. If the IN call is not put through tothe real subscriber communicated by the SCP in the simulation, which thetraffic generator determines taking into account the probabilitiesspecified for this purpose, the traffic generator generates the EVENT INmessage as the follow-up event, which is used, for example, to requestrerouting information from the SCP. The traffic generator is thus ableto generate IN-typical event sequences that largely correspond to thereal traffic volume in the IN.

The following parameters are stored for each IN event: the callidentification number, time t1 at which the SSP sends the message, themessage identification number, e.g., 1 for PROVIDE INSTRUCTION, 2 forEVENT, 3 for EVENT(CALL END), the service identification number, e.g., 3for TIS, 5 for UNU, 6 for FPH, 10+j (J=0, . . . , 89) for the jthservice subscriber of the TV service, and an SSP identification number.

In one advantageous embodiment of the present invention, a global title(GT) code is also generated as a routing criterion and stored as aparameter of the IN event, thus providing a global title translation inthe IN. The GT class is also generated by a preset probabilitydistribution. The STP/SRP simulator then preferably activatesGT-specific process chains which simulate the routing functions on theSTP/SRP level, e.g., the switching of a call to the network of adifferent network provider.

It is also advantageous to assign the events generated by the trafficsimulator to user and load classes. Call-specific IN events are assignedto a user class, while management traffic between the IN levels, forexample, can be simulated by events in a load class. For each eventgenerated by the traffic simulator, the system generates and stores acorresponding class identifier, which is detected by the othersimulation modules and may help determine how the event is to beprocessed.

In online mode, the traffic generator generates the follow-up eventsduring the simulation run with the given probabilities after thecorresponding first events have passed through the SCP simulator andpossibly the SS7 simulator modules, i.e., after an event correspondingto the CREATE-JOIN message from the SCP is generated by the SCPsimulator and is provided to the traffic simulator for processing,possibly after passing through the SS7 simulator. In online mode,feedback loops between the simulation modules are thus automaticallytaken into account when the traffic simulator generates IN-specificevent sequences.

In file mode, feedback loops of this type can be produced only throughiteration, since the simulation modules are invoked sequentially. Thefirst time the traffic simulator is invoked, therefore, the first eventsare generated in the manner described above, and a preset SCP responsetime that is, for example, constant over time, is initially assumed forthe follow-up events. The next time the traffic simulator is invoked,the response time is corrected by the response times derived from thetransfer file transferred by the SCP simulator or the SS7 simulator tothe traffic simulator. Multiple passes of the simulator yield a steadystate which largely also takes into account interactions between themodules.

In online mode, the IN-specific first events are generated while theoverall simulation is in progress, i.e., at each simulation time, forexample in ns intervals. This also makes it possible to simulatemanipulation of the overload protection mechanism during aninstantaneous overload of the remaining simulation modules and to rejecta call before a corresponding IN event is generated or forwarded.

According to the theoretical traffic method described above, a sequenceof calls arriving at the SSP or at the SSPs which normally produce an INevent can, however, be generated before the simulation begins andprocessed during the simulation, i.e., they can be forwarded as INevents or rejected by the overload protection mechanism.

The utilization of the signaling channels in the intelligent network canbe determined for each simulation time based on the generated trafficvolume. The number of voice connections occupied to and from the SSPsand/or the number of serving lines occupied for subscribers of thefreephone service can also be logged and output as a function of time,based on the user-defined probabilities concerning the further progressof the call (e.g., a call or recorded announcement of a certain averageduration). It is also possible to output, as a function of thesimulation time, the number of calls that were rejected at variousstages, e.g., directly after generation by the overload protectionmechanism, at the end of a timeout if the SCP does not respond, or ifall attendant consoles are busy.

FIG. 7 shows a flowchart of the simulation in file mode. After thesimulator is started, the input files are read in by the individualsimulation modules. The traffic simulator determines whether a filecontaining messages from the SCP already exists (transfer file 204 fromFIG. 2 or 307 from FIG. 3). If it does, the traffic simulator analyzesthis data to determine the SCP response times and takes them intoaccount when generating the event sequences. If it does not exist, thesystem moves on to the next step without performing an analysis and usesa default value for the SCP response times. The counters are initializedby setting an internal simulation clock to a time of zero and settingthe status variables and statistical counters to initial values.

In the next step, a start event is generated, i.e., a first PROVIDEINSTRUCTION message, and entered in the event calendar. During thesimulation, the event calendar contains all events not yet processed,organized by their start times.

After initialization, the actual simulation begins in a loop. First ofall, the abort condition is interrogated, with the simulation beingaborted if instantaneous simulation time t exceeds a preset simulationduration. In the loop, the next event is first output from the calendarand the simulation clock is incremented to the time of the next event.At the time the simulation is started, this next event is the firstevent generated after the simulation. The event type of the event to beprocessed is determined and the corresponding event routine subsequentlyexecuted.

This example provides nine different types of events. From left toright, these are the arrival of a new call (NEWCALL), the arrival of arepeated call attempt (FOCALL), the receipt of the CREATE-JOIN messagefrom the SCP (CONNECTSSPCON), a call setup to the B party (CONNECT B),call forwarding (REROUT), the receipt of the CREATE-JOIN message fromthe SCP after call forwarding ((REROUTCON), the end of the call(TALKEND), the end of a recorded announcement (TAPEND), and therejection of a call (REJECT).

The first event entered in the calendar is usually a new call (NEWCALL).The event routine assigned to this event causes the traffic generator togenerate the next call and to simulate the call setup procedure to theSSP. The NEWCALL event routine simulates the transmission of an INmessage (PROVIDE INSTRUCTION) from the SSP to the SCP by generating acorresponding event and entering it in the event calendar or thetransfer file.

The SCP subsequently sends the CREATE-JOIN message to the SSP; in thesimulation, the receipt of the CREATE-JOIN message from the SCP istherefore entered in the event calendar as an event occurring at theinstantaneous simulation time plus the SCP response time. This ends thefirst event routine; the simulation clock is put forward to the nextevent time, and this event is read out from the calendar and processed,unless the simulation time has already expired. The simulation skips thetime between two events.

Let us assume that the next event is the receipt of the CREATE-JOINmessage from the SCP. The continued call setup procedure from the SSP,using the event routine (CONNECTSSPCON), is simulated. For example, thisroutine determines, based on the probabilities described above, whethera call is successfully set up to the B party (follow-up event:CONNECTB), in which case the B party can be a real subscriber or arecorded announcement; or whether a call must be rerouted following apreviously unsuccessful forwarding attempt (follow-up events: CONNECTBor REROUT). When the CONNECTB event is retrieved, the connection is setup to the B party. The follow-up events are Talk-End or Tape-End, whosetimes are derived from the average call or recorded announcementduration and the instantaneous simulation time. If the call setupattempt is unsuccessful, a follow-up call is generated with a certainprobability, and the FOCALL event entered in the event calendar. Therepeated call attempt is subsequently handled just like a first callattempt.

The loop, i.e., retrieving an event from the event calendar, running thecorresponding event routine, possibly generating a follow-up event andentering it into the event calendar, setting the simulation time to thetime of the next event entered in the event calendar, and retrievingthis event, is repeated until the simulation time set earlier has beenreached or until an event occurs that marks the end of the simulation.At the end of the simulation, the data entered in the event calendar orin log files and generated and processed by the simulator is availablefor evaluating the performance of the intelligent network or individualcomponents.

FIG. 8 shows a flowchart of the simulation in online mode. First of all,the user sets up the configuration, with the corresponding configurationfiles being read in by the simulation modules. In the example shown inFIG. 8, the traffic, SS7, SCP, and overload protection (ACG) simulatorsare active and are administered by the common organization program, theonline simulator. As described in the description of FIG. 7, the trafficsimulator first generates a start event. The global simulation clock isset to t=0. Like the simulation run illustrated in FIG. 7, the eventsentered in the global event calendar are retrieved in chronologicalorder in a loop, the corresponding event routines executed, and anyfollow-up events generated entered in the global calendar. At the end ofeach event routine, the simulation time is put forward to the time ofthe next event, and this event is processed. A predetermined maximumsimulation time, which is compared to the instantaneous simulation timefor each pass through the loop, is again set as the abort condition forthe loop. Upon reaching the end of the simulation, the partialsimulations are terminated by releasing the dynamic memory. If the endof the simulation is not reached, the shared memory, which the userinterface accesses during the simulation, is updated so that theinstantaneous system data can be displayed directly for the user. Thesystem data for the overload protection simulation is also updated. Thedetermined measured data, i.e., the SCP utilization, queue length, etc.,is then logged at regular intervals, entered in the corresponding logfiles, and/or displayed for the user. Finally, the next event entered inthe calendar is processed.

The example illustrated here distinguishes between a total of 13 globalevent types, which can be divided into two groups: Internal events:internal events are routines that influence the status of only oneindividual simulation module. Each simulation module is an independentevent-oriented program with a plurality of events and a separate localcalendar for administering the events. From the perspective of thesequence control system for the overall simulator, this example includesthree global internal events (TRAFFIC_INTERN, SS7_INTERN andSCP_INTERN), each of which provides a reference to the local eventcalendar.

FIG. 9 shows a schematic diagram of the processing sequence for aninternal event of this type from the perspective of the onlinesimulation. As each subcomponent is invoked, the next internal, andpossibly the next external, event is generated and entered in the localcalendar of the simulation module as a function of the internal programrun. In addition, all necessary event parameters are transferred to thesequence control system so that they can be assigned to the globalcalendar of the overall simulator.

The remaining events in the simulation run illustrated in FIG. 8 areexternal events that are used for communication between the simulationmodules. They correspond to the messages sent from one component toanother in a real intelligent network, e.g., PROVIDE INSTRUCTION,CREATE-JOIN or EVENT. The external events that occur here are: PROINSTTO SS7, EVENT TO SS7, and SSP CALLEND TO SS7, which correspond to thePROVIDE INSTRUCTION, EVENT, and EVENT (CALL END) messages sent from theSSP to the SCP. The above-mentioned internal events are generated by thetraffic simulator (TRAFFIC_INTERN routine) and correspond, in file mode,to the events entered in first transfer file 304 (in FIG. 3).

External events PROVINST TO SCP, EVENT TO SCP, and CALL END TO SCPrepresent PROVIDE INSTRUCTION, EVENT and EVENT(CALL END) messages, whichare transferred from the SS7 system or the SRP/STP to the SCP. Theseevents thus correspond to the events entered in second transfer file 305(in FIG. 3).

In response, the SCP sends the SCP CALL END TO SS7 and CREATE-JOIN TOSS7 events. The first of these events confirms the call release, whilethe second simulates the transmission of call setup information. Theseevents correspond to the events entered in third transfer file 306. Theyare generated by the SCP simulator and address the SS7 simulator. Theextern events CALL END TO SSP and CREATE-JOINT TO SSP are generated bythe SS7 simulator and are used to forward a message from the SCP to anSSP via the SS7 system. The corresponding events are stored in fourthtransfer file 307 in file mode.

The CALL END TO SSP message is needed only if the SS7 is inactive.

To process an external event within the sequence control system, thecorresponding message is entered in one of the simulation components. Indoing this, the message can cause the component to generate a newinternal event that is then forwarded to the online simulator andentered in the global calendar. After an event routine is executed, thenext event is output from the global calendar and the simulation clockis updated, i.e., set to the start time of this follow-up event.

When processing the internal event TRAFFIC_INTERN, the traffic simulatoris invoked and generates a new call. Based on the instantaneous load onthe remaining simulation modules, the system decides whether theoverload protection simulator (ACG) will reject this new call. If theoverload protection simulator rejects the call, this action is logged,and the event routine ends. If the new call is not rejected, it is addedto the simulation, i.e., the corresponding PROVINST TO SS7 event iswritten to the global event calendar. A new element for the generatedcall is placed in a log file, with the following data being stored: theidentification number of the call that was generated by the trafficsimulator when the call was generated, the service identificationnumbers of the call, the number of the SSP receiving the call, themessage identification number, i.e., an indication of whether thePROVIDE INSTRUCTION or EVENT message is present, and time t1 at whichthe PROVIDE INSTRUCTION or EVENT message corresponding to theinstantaneous call was generated. During the course of the simulation,additional time stamps are added to this log line after the SS7simulator has executed the PROVINST TO SCP or EVENT TO SCP routine (timestamp t2), after the SCP simulator has executed the CREATE-JOIN SS7routine (time stamp t3), and after the SS7 simulator has executed theCREATE-JOIN TO SSP routine (time stamp t4).

CALL END messages are not logged because the delay times they produce donot contribute to the waiting time of an IN caller and would thereforecorrupt the information relating to the response times. If the problemposed is modified, however, it could be useful to also log these timestamps.

The second and third time components contain valid values only if theSS7 simulator was active during the simulation.

Because a complete data record for a single call is produced only at thetime when the CREATE-JOIN message arrives at the SSP, the data mustfirst be buffered. A new data record, to which the missing timecomponents are added during the further processing of the program, iscreated when a call is generated. The following response times can bedetermined by calculating the differences between the individual timestamps assigned to a call:

t2−t1: delay of a message in the SS7 on the way to the SCP;

t3−t2: delay of a message in the SCP;

t4−t3: delay of a message in the SS7 on the way to the SCP;

t4−t1: total delay of a message in the IN.

The network utilization is stored at regular intervals during thesimulation run. Global, statistic network data, and not call-specificinformation, is stored. The following quantities are preferably logged:the time of the instantaneous measurement, the number of calls arrivingin the IN per second, the number of messages currently being processedby the SS7 that are on the way to the SCP, the number of messages in theSCP, and the number of messages in the SS7 that are on the way to theSSP.

The SCP simulator determines the utilization, queue length, and thenumber of messages processed (dispatches) for each processor and storesthem in a log file. The online simulator accesses this data and writesthe values determined across all CPUs to a file. The data can bedisplayed on the user interface during the online simulation.

Finally, the number of lines occupied to and from the SSPs is determinedon the basis of the traffic data and logged as a function of thesimulation time.

As a supplement to FIG. 8, FIG. 8a shows the relationship between theevents used. A separate module for simulating the SRP, which can alsoform part of the SS7 simulator, was added to the simulator in FIG. 8,which is why SRP INTERN events also occur here. The four internal eventsTRAFFIC_INTERN, SS7_INTERN, SRP_INTERN, and SCP_INTERN invoke asimulation module so that it will process an event. All other externalevents are used to switch from one simulation module to the next. Thestart event in the overall simulation is always a TRAFFIC_INTERN event,since the traffic simulator is the source of the IN calls.

After processing an internal event, each simulation module can generatea follow-up event to be processed by the same simulation module. At thesame time, one of the external events marked by a descending arrow canbe generated. The online simulator receives this information from thecorresponding simulation module.

Retrieving an external event is identical to sending a message to theother node in the IN. There are three message types that can be sent.These messages are reflected by three different transitions from thetraffic generator to the SCP simulator. A TRAFFIC_INTERN event isretrieved, which generates this message and assigns a unique number(CallID) to this call during the simulation. Depending on the message,this is followed by a PROINST TO SS7, EVENT TO SS7, or SSP CALLEND TOSS7 event and a further TRAFFIC_INTERN event, if more traffic needs tobe generated. The external event is then processed and results in anSS7_INTERN event. This event is generated multiple times in successionuntil the SS7 portion of the SSP has completed all processing operationsand an external event for the SRP is generated. The message does notchange during this process, i.e., an incoming PROVIDE INSTRUCTIONmessage is also forwarded as such. This external event is then followedby multiple SRP_INTERN events, just like with the SS7-INTERN event. Itis transferred to the SCP_INTERN event in the same way that theSS7_INTERN event is transferred to the SRP INTERN event.

After an SCP-INTERN event has been processed multiple times, the SCPsimulator asks the online simulator to send a message to the SSPsimulator. For this purpose, there are two different messages,CREATE_JOIN and CALLEND, which are forwarded to the SS7 simulator in thesame manner described above and produce an SS7_INTERN event. However,only CREATE JOIN events produce a TRAFFIC INTERN event from here;CALLEND events do not cause the traffic generator to generatecorresponding follow-up events. Nevertheless, it is possible toconfigure follow-up calls which are started by the traffic simulator ata time defined by the random number generator if a connection could notbe set up. These calls have the same CallID as the original call.

If the traffic simulator is invoked by a TRAFFIC_INTERN event thatfollows a CREATE-JOIN event, the random number generator determines whenthe next message relating to this event will be sent, based on thepredetermined probabilities. The event chain described above is thenstarted at this time.

If more than one call is generated, this chain of events is applied toeach call. The events of multiple overlapping calls are processedaccording to their positions in the global event calendar.

The structure of the SCP and SS7 simulators is discussed below.

FIG. 10 shows a schematic diagram of the basic SCP simulation sequence.Once again, it is an event-controlled simulation, with only discreteevent times being observed and state changes occurring at each eventtime.

The SCP simulator has a local event calendar in which all events to beprocessed by the SCP simulator are entered in chronological order. Thefollowing event types exist: Messages: messages represent requests fromthe SSP or SS7 to the SCP for call handling instructions, with thearrival of a message in the SCP or the SCP simulator starting a serviceprocessing program composed of a presettable sequence of processes. Amessage corresponds to a global external event. (Local) internal event:a local internal event ends a process or event and generates a newprocess or a corresponding event, with the type and attributes of thisevent being derived from the process chain defined in the serviceprocessing program. (Local) external event: a local external event isgenerated when a service processing program ends, i.e., after executingthe last process specified in the process chain. An external eventcauses a message to be sent to the SSP or SS7, thereby generating aglobal external event and entering it in the global event calendar.

FIG. 11 shows one example of a configuration parameter in the SCPsimulator. The upper portion of the table contains a list of allprocesses to be simulated that can be executed by the SCP andparticipate in the connection setup or release process. The individualprocesses are identified by a process identification number (processID); the process name is indicated only to make it easier to adapt theconfiguration to the function of a real SCP. To each process is assigneda process duration, which in this case is indicated in milliseconds, aswell as a priority. The settings can be defined by the user, making itpossible, for example, to determine the effects of a change in priorityassignment or a change in process duration using the simulator.

The lower portion of the table contains the user-definable SCP servicerun. A process sequence is assigned to each service, identified here bythe service identification number, and to each service-specific PROVIDEINSTRUCTION, EVENT or EVENT(CALL END) message, identified by the messageidentification number. The process sequence or the service processingprogram is defined by consecutive indications of the process ID for theprocesses listed above. In addition, a CPU on which the process sequenceis executed is assigned to each message according to service. It is alsopossible to process all messages on all available CPUs.

An individual process can also be divided into any number ofsubprocesses, between which other processes can be inserted into theprocess sequence. If the first subprocess in a process sequence occupiesa copy corresponding to the process ID, it continues to occupy this copyuntil the last subprocess has been completely processed. All serviceprocesses have a characteristic of this type.

To simulate cache or hard disk access or the incrementing of countersfor the TV service, wait processes can also be inserted into the processsequence. In doing this, the average waiting time and its variation mustbe set; the actual waiting time is derived from the average waiting timeduring the simulation based on a given probability distribution usingthese parameters, e.g., a Gaussian distribution.

As shown in FIG. 11, it is also possible to specify, as one parameter,the delay in the ST2000 front-end system, which forms the interfacebetween the SCP and the SS7 system in some network topologies, as wellas the maximum counter status for the televoting service.

FIG. 12 shows a model, based on the SCP simulation, for the processmanagement of a CPU 1201 within an SCP. In principle, however, any modelof this type of process management in the SCP simulator can be used bydefining the queues or event calendar accordingly. The processmanagement only determines the number and type of links between the SCPqueues and local event calendars within the SCP simulator, and thus theway in which a message or the resulting individual processes areexecuted in the simulator. The simulator can be adapted to customersettings with a high degree of flexibility, making it possible tosimulate any real situation. No specific hardware and/or software layoutis specified, but rather any configuration can be modeled.

In the situation illustrated in FIG. 12, CPU 1201 is connected to theSS7 by two local area networks (LANs) 1202, 1203, for example using twoToken Bus LANs, via the ST2000 front-end system.

Messages 1208 (PROVIDE INSTRUCTION) arriving at the SCP are written toservice-specific queues 1204, 1205, 1206, 1207, depending on theservice. A process or a message waits in this queue for external orinternal messages that invoke the process so it can be executed. If aprocess contains the desired message, it enters the queue of activeprocesses. In this priority queue 1210, the active processes arearranged according to priority, while the events entered inservice-specific queues 1204 through 1207 are organized in chronologicalorder. The process having the highest priority in priority queue 1210 isreceived by the CPU, where it is executed. For example, if a processcannot be executed by the CPU because all incarnations of the process tobe invoked are in use, this non-executable process is administered in anadditional queue 1209 until a process incarnation is available again andthe process changes to the executable state; it is then entered inpriority queue 1210.

FIG. 13 shows a further model of the process management system of a CPUfor simulating the SCP functions. Messages arriving at a CPU 1301 areconverted to a process sequence according to the service processingprogram. The first of these processes is entered in a process-specificqueue 1302, 1303, 1304, 1305 so that it can be executed by assignedprocess routine 1307, 1308, 1309, 1310. The incoming processes arearranged in chronological order in process-specific queues 1302 through1305. To each process routine 1307, 1308, 1309, 1310 is also assigned acertain priority P1 through Pn. It is also conceivable to haveconfigurations in which queues 1302, 1303, 1304, 1305 arepriority-specific only, i.e., all processes, including different ones,take on a certain priority and can then be executed in chronologicalorder.

Multiple incarnations of the process routines can be provided for thesame process, for example one copy per service. In this case, processspecific queues 1302 through 1305 are also service-specific. If aprocess routine 1307 through 1310 is ready, the next process isretrieved from corresponding queue 1302 through 1305; the process isthen ready. If CPU 1301 is also available, it executes the process.After a process has been executed, CPU 1301 generates the processfollowing the process in the process chain that was just executed andenters it in the corresponding queue. Non-executable processes areadministered in an additional queue 1306 until they switch to theexecutable state. Interrupted, yet executable, processes are placed atthe beginning of their queues and are executed next, if this ispermitted by their priority.

Processes in progress can be interrupted, for example, by processes orevents that simulate the CPU operating system. Events of this type areassigned a higher priority in the simulation than are service-processingprocesses. The user can set the average time which the CPU should applyfor executing such processes. A process of this type is then generatedby a random number generator.

FIG. 14 shows a schematic, object-oriented model of an SCP simulator.The simulator has a plurality of subunits, each of which simulates thefunction of a CPU 1401, 1402, 1403, 1404. These subunits can be combinedas modules to form the SCP simulator.

The ST2000 front-end system (reference number 1405) receives an incomingmessage and forwards it to a CPU 1401 through 1404 for completeprocessing depending on predetermined CPU selection criteria. Front-endsystem 1405 is simulated with a constant delay time. It can also have aseparate queue in the SCP simulator.

A follow-up event, e.g., the EVENT or EVENT(CALL END) message, isautomatically processed on the CPU which handed the first event, sincein reality this is the only place where the call context is stored.However a first event (PROVIDE INSTRUCTION) can be assigned to a CPUaccording to different criteria: for example, statistic data of the SCPsimulator can be used, including CPU utilization, the number of messagesto be processed in the CPU together with the present status of the CPU(active or inactive), the total waiting times remaining for allprocesses running on the CPU or waiting processes. However, this meanscomputing time during the simulation in progress must be devoted todetermining the statistic data and thus making a selection.Alternatively, the CPUs can also accept the messages independently: allfirst events (corresponding to the PROVIDE INSTRUCTION messages) arewritten to a queue shared by all CPUs; the follow-up events(corresponding to the EVENT or EVENT(CALL END) messages) are entered inCPU-specific and possibly also CPU- and message-specific queues. If aCPU's processor is available, the next message can be automatically readout from a CPU-specific or shared queue.

As it is processed, the event passes through a fixed process sequenceduring the CPU simulation, as shown in FIG. 11, for example. Eachprocess in the process sequence can also be divided into a plurality ofsubprocesses, with other processes being executed between thesubprocesses. For each process, the CPU contains at least one processroutine 1408, 1409, 1413 through 1416, which can be used to execute theprocesses entered in process queues 1410, 1411 when their turn comes.Multiple incarnations of a process routine can also be provided on theCPU, with an event being assigned, for example, to one of the processroutines according to service. In FIG. 14, this is represented by twoblocks of process routines 1408, 1409, 1413, and 1414 through 1416, withone process queue 1410 or 1411 each.

An incoming event is processed as follows: The event is first entered inprocess queue 1410 or 1411 and waits until the process routine of theprocess to be retrieved becomes available. When the process is ready,the event is placed in the priority queue. The events entered inpriority queue 1407 are processed by CPU 1401 consecutively. While theCPU is executing a process, wait events can occur which, for example,simulate hard disk access. These wait events are generated randomly oraccording to process and entered in a queue 1412. These events have ahigher priority and interrupt the process running on CPU 1401.

While a process is being executed, service-specific counter events canbe requested which are generated by a counter 1406. This counter 1406can receive requests from all CPUs, and these requests can also blockeach other. This delays the process execution times, although it doesnot place any load on the calling CPU.

To obtain SCP statistic data, the SCP simulator determines the CPUutilization as follows: at each time specified by the user, i.e., everyn simulation seconds, the system calculates what percentage of timewithin completed, user-defined interval Δt the CPU was active, i.e., alltimes of the individual processes running during last interval Δt areadded up and their percentage of interval Δt calculated.

The queue length, which is another SCP load criterion, is deriveddirectly from the length of the respective queues or local eventcalendars.

FIG. 15 shows the arrangement of the SS7 layers that take part in thedialog between the SSP and SCP and are therefore simulated with the SS7simulator. Top layer 1501 is the layer for the SS7 users, and thereforerepresents the link between the SSP or SCP and the SS7. This layer sendsand receives messages to and from the intelligent network or the SS7.Next come the following layers in the order given: TCAP layer 1502, SCCPlayer 1503, and MTP layers 1504 (levels 3 to 1), each of which uses aseparate processor to perform specific SS7 functions. The flow ofmessages from the SSP to the SCP is carried out in the manner shown inthe right portion of the drawing, passing from layer 1501 to 1504 andback to 1501, and is bi-directional.

SS7 levels 1502 through 1504, i.e., TCAP, SCCP, and MTP 1-3, are modeledseparately to simulate the SS7. The individual processes on a level aresimulated by delay times. A queue model is used to simulate the flow ofsignaling messages on one level, or between two levels.

As an example of this, FIG. 16 shows the model of MTP3 level 1008 of theSRP in the SS7 simulator. The three processes that occur on this levelare MESSAGE DISTRIBUTION (HMDT), MESSAGE DISCRIMINATION (HMDC), andMESSAGE ROUTING (HMRT). The way in which the processes behave towardeach other and toward adjacent layers SCCP 1607 and MTP2 1609 isillustrated by a flowchart in FIG. 16a and by a flowchart with localprocess queues 1601, 1602, 1603 in FIG. 16b.

Process HMDC 1604 receives signaling messages from the MTP2 level anddistributes them according to the message destination nodes. Beforebeing processed by HMDC process 1604, the messages are placed incorresponding process queue 1603. Messages sent to the local nodes,i.e., to the SRP assigned to MTP layer 1608, are forwarded to HMDTprocess 1605. They are placed in corresponding process queue 1601 and,after being processed by the HMDT process, are transferred to SCCP 1007.If a message is destined for a different node, HDMC process 1604transfers it to HMRT process 1606. The latter forwards the message toMTP2 level 1609 after it is processed, i.e., after it is retrieved fromcorresponding process queue 1602. The same applies to messages that MTP3level 1608 receives from SCCP 1607.

FIFO queues 1601, 1602, 1603 used in FIG. 16b can accept multiplesignaling messages and process them consecutively. The processing orderdepends on the delay time in each case and is entered in the local eventcalendar of the SRP or SS7 simulator.

FIG. 17 shows a model of the TCAP layer of the SS7 as a further example.According to the representation in FIG. 15, TCAP layer 1702 is locatedbetween SS7 USER layer 1701 and SCCP layer 1703. Arrows indicate themessage flows between the layers and within TCAP layer 1702. In thisexample, TCAP layer 1702 simulates four processes: INVOCATION STATEMACHINE 1704, COMPONENT COORDINATOR 1705, DIALOG HANDLING 1706, andTRANSACTION SUB-LAYER 1707. To each of these processes is assigned aprocess queue 1708 through 1711. After an event entered in one of thequeues has been processed, a follow-up process is invoked from the samelayer or the message forwarded to the next higher or lower SS7 layer,depending on the message flow illustrated here. The process sequencescan be defined by the user and flexibly adapted to the real process flowwithin a TCAP layer.

FIG. 18 shows an example of configuration parameters in the SS7simulator. As the first step, the process times for the processesinvolved in communication between the SSP and SCP can be specified forthe individual SS7 layers. In this example, only the process times ofthe TCAP and SCCP processors on the SSP and SCP sides and the processorson the MTP3 level in the SSP, STP, and SCP area are given. In each case,three or four processes are used per level. Like in the SCP simulation,the process sequence in the SS7 layers can be defined by the user withthe service processing program and can thus be flexibly adapted to realconditions. The individual processes can also be assigned a specificpriority, although this is not illustrated in the figure.

The lower portion of the table shown in FIG. 18 contains theuser-definable parameters relating to the topology of the intelligentnetwork in the SS7 area, e.g., the number of SCPs, the number ofsignaling channels between the SSP and STP and between the STP and SCP,the runtime-specific message delay between the STP and SSP or SCP, andthe delay between the processors. The message length can also bespecified.

FIG. 19 shows how overload protection simulator 1903 is implemented inthe IN simulator in online mode as well as its principle operation. Inthis example, overload protection simulator 1903 regulates the trafficvolume generated or forwarded by traffic simulator 1902 on the basis ofsystem data that enables conclusions to be drawn about the instantaneousload situation, particularly that of the SCP simulator, with this databeing administered by online simulator 1901, and transferred to overloadprotection simulator 1903 via the online interface.

In the example illustrated here, overload protection simulator 1903regulates the traffic volume generated or forwarded by traffic simulator1902 according to the Automatic Call Gapping (ACG) principle: forexample, only one call, possibly with predetermined attributes, can besent from the SSP to the SCP within an interval Δt1 (gap time). IntervalΔt2 (gap duration) indicates how long a reduction operation of this typelasts. Overload protection simulator 1903 can also be used to simulateoverload protection mechanisms according to the “leaky bucket”principle.

Overload protection simulator 1903 (overload process) is invoked bytraffic simulator 1902. In doing this, the latter transfers a call withthe relevant parameters, such as service, message, SSP identificationnumbers, or time. In addition to this data, the overload processreceives the instantaneous system data, such as CPU utilization,response times, and queue length, from online simulator 1901. Once theoverload process has been initiated, it is controlled by its owncounters and the transferred system data. A separate counter can beprovided for each SSP, service, and/or service class. After the call hasbeen recorded by the corresponding counter, the overload protectionsimulator calculates the instantaneous overload level using the systemdata. The gap parameters are then read out from the initialization tablefor the instantaneous overload level. The initialization table is storedin the initialization file, which is retrieved when overload protectionsimulator 1903 starts. The gap parameters include interval Δt1 (gaptime), within which only one call, possibly with predeterminedattributes, can be sent from the SSP to the SCP, and interval Δt2 (gapduration) which indicates how long a reduction operation of this typelasts.

To calculate the instantaneous overload level, all calls within apresettable time window are counted and possibly weighted in time. Thisweighting advantageously depends exponentially on the age of the call,with a more recent call being given a greater weight than an older call.In addition, the load is distributed to the SSPs or to the services,making it possible to also simulate service- and/or SSP-dependentoverload protection, in which case calls having certain attributes aresuppressed selectively.

The user can define different overload levels to which are assigneduser-defined gap parameters.

After the overload level has been calculated, the gap operations areupdated accordingly, e.g., the length of time interval Δt1 or Δt2 isadjusted. The system then checks whether or not such operations apply tothe instantaneous call. If it was successful, the process to be invokedis then assigned the return value TRUE or some other identifier;otherwise it is assigned the value FALSE, or another assignedidentifier.

Traffic simulator 1902 evaluates the return value. If the value isFALSE, a follow-up call is generated based on a preset probability. Ifit is TRUE, traffic simulator 1902 forwards the call to the onlineinterface, from where it is transferred to the SCP or SS7 simulator. Thetraffic simulator then generates a new call, and the process begins allover again.

FIG. 20 shows how overload protection simulator 2002 is implemented inthe IN simulator in file mode. In file mode, the calls are firstgenerated by the traffic simulator and placed in a transfer file 2001.Because it is not possible to transfer any instantaneous system data tooverload protection simulator 2002 in file mode, the simulator itselfmeasures the instantaneous load in the form of calls per time unit. Theinstantaneous load is compared to a predetermined value for the maximumnumber of calls sent by the traffic simulator; this number is stored,for example, in the initialization file. The instantaneous overloadlevel is calculated on the basis of the instantaneous incoming load andthe maximum outgoing load. Like in online mode, the new protectionparameters are read out of the initialization table and the protectionoperations updated.

FIG. 21 shows an example of simulation data determined by the INsimulator. This representation is based on the configuration establishedby the configuration files shown in FIGS. 6, 11, and 18. The SS7simulator is active, while the overload protection simulator isinactive. A telephone traffic volume of 30 calls per second at intervalsof 0 to 500 seconds is specified.

FIGS. 21a through 21 c show the data determined by the simulator fornetwork statistics. FIG. 21a shows the preselected average telephonetraffic and the telephone traffic generated by the traffic simulator asa function of the simulation time. The set telephone traffic isrepresented by the dotted lines and corresponds to the settings shownabove, i.e., 30 calls per second remain constant at intervals from 0 to500 seconds, followed by 0 calls per second. The generated telephonetraffic, represented by the solid line, shows statistical fluctuationsabout the preselected average value. It drops to zero after time t=500seconds.

FIG. 21b shows the SCP response time in seconds as a function of thesimulation time. With a constant telephone traffic of 30 calls persecond, the steady state sets in according to this simulation result,i.e., the SCP processes the requests sent to it with a response time of0.4 to 0.7 seconds.

FIG. 21c shows the number of messages provided in the SCP simulator forprocessing as a function of the simulation time. According toexpectations, the number of calls in the SCP and the SCP response timecorrelate strongly to each other.

FIGS. 21d to 21 f show SCP statistic data as a function of time, i.e.,CPU utilization as a percentage, number of messages in a CPU queue, andthe number of processes executed by a CPU per time unit, The figuresshow the maximum, minimum, and average CPU utilization, queue length,and number of dispatches. The number of messages that are beingprocessed at a given time in the SCP fluctuates on average between 20and 60 in the representation in FIG. 21c, while the queue contains anaverage of only 6 messages as shown in FIG. 21e. These values, as wellas the average CPU utilization of 80%, lead to the conclusion that theSCP can easily handle a traffic volume of 30 calls per second in theselected configuration.

FIGS. 21g to 21 i show SS7 statistic data. FIG. 21g corresponds to 21 aand shows the set or generated telephone traffic as a function of thesimulation time. FIG. 21h shows the delay of a message in the SS7simulator on the way from the SSP to the SCP (broken line) as a functionof time, as well as the delay of a message on the way from the SCP tothe SSP (dotted line). FIG. 21i shows the number of messages in the SS7in the direction of the SCP (broken line) and in the direction of theSSP (dotted line) as a function of the simulation time. The delay timesin the signaling system are far below those in the SCP and reach amaximum value of 0.045 seconds.

FIG. 21j shows the SSP statistic data as a function of time, i.e., thenumber of lines occupied to and from SSP1 and SSP2 (left and rightcurves). The number of lines occupied to and from the SSPs reaches asteady state at around 300. At time T=300 seconds, the entire telephonetraffic switches from SSP1 to SSP2. This condition was set in thetraffic file.

FIG. 22 shows a further example of simulation data determined by the INsimulator, in this case with a greatly fluctuating traffic volume. Thetraffic volume was varied every 100 seconds, from 40 to 20, to 80, to10, to 50, and to 5 calls per second. The SS7 simulator is active, whilethe overload protection simulator is inactive. The illustrations areassigned to the simulated quantities in the same manner as in FIG. 21.

FIG. 22a shows that the generated traffic follows the set traffic volumeup to time t=250 seconds, with the generated traffic volume beingdistorted by statistical fluctuations. At time t=250 seconds, thegenerated traffic volume, i.e., the number of messages generated by thetraffic simulator that reaches the IN, drops significantly compared tothe preset volume. This can be seen in FIG. 22j. All lines leading tothe network are occupied at time t=250 seconds, so that only a smallportion of the calls can lead to an IN event.

Without manipulating the overload protection simulator, the SCP responsetime increases significantly in the simulation shown in FIG. 22 as soonas the limit of 30 calls per second is exceeded. The number of calls inthe SCP and the SCP queue length also increase significantly. As soon asthe volume drops below this limit value of 30 calls per second, the SCPis able to process the waiting messages so that the delay time and alsothe queue length decrease. The time needed to process the messages inthe central signaling system fluctuates by only 0.02 seconds in spite ofthe different traffic volumes.

FIG. 23 shows a simulation using the same set traffic volume as in FIG.22, but in this case with the overload protection simulator activated. Amaximum traffic volume of 30 calls per second was set for the overloadprotection simulator. FIG. 23a shows that the generated traffic volumeis limited to this average of 30 calls per second. As shown in FIG. 23b,the SCP response time is therefore reduced to a value of around 0.4 to0.5 seconds, which corresponds to the SCP response times at a constanttraffic volume of 30 calls per second shown by the example in FIG. 21.The response times are therefore lower by a factor of 100 compared tothe example shown in FIG. 22.

In all stages of planning and operating an intelligent communicationnetwork, the IN simulator according to the present invention is a usefultool for testing network performance, adapting it to certainspecifications, and locating weak points. Due to the great flexibilityof the simulation modules, the simulator can be easily adapted to givenas well as future realities. Through comparison to simulated values andthe parameters on which the simulation is based, the configuration ofthe real intelligent network can be selected to achieve the highestpossible IN efficiency under the given basic conditions. This greatlyreduces the costs of operating and planning intelligent networks, sincethe IN simulation can be used to determine an optimum configuration forthe intelligent network and its components and apply it directly to realsituations without having to waste costly experimentation time in thereal IN. The IN simulator is a suitable tool for determining managementparameters that can, for example, establish a stable basis for theproblematic overload protection mechanisms. The simulation results alsomake it possible to develop and test general global or node-specificmanagement functions that can be implemented and used more effectivelythan the overload protection mechanisms used up to now.

List of Reference Numbers

Exchange 101 SSP 102 STP and SRP 103 SCP input processor 104 Telephone Bchannels 105 SS7 channels 106, 107, 108 SCP 109 Traffic simulator 201,301, 401, 1902 SCP simulator 202, 302, 402 SS7 simulator 303, 403, 503Transfer files 203, 204, 304, 305, 306, 307, 406-409, 2001 SCP outputfile 205, 308, 423 Traffic output file 206, 309 SS7 output file 310 SCPinput file 207, 311, 416 Traffic input file 208, 209, 210, 211, 212,312-316, 411-414 SS7 input file 317, 415 Overload protection simulator404, 502, 1903, 2002 User interface 410 Log files 417-420 File name file421 Overload protection input file 422 “Black box” 501 CPU 1201, 1301,1401, 1402, 1403, 1404 LAN (for connection to the SS7) 1202, 1203Service-specific queues 1204, 1205, 1206, 1207, 1410, 1411 INmessage/event 1208 Queue for non-executable processes 1209, 1306Priority queue (for activated, 1210, 1407 executable processes)Process-specific queue 1302, 1303, 1304, 1305, 1601, 1602, 1603 Processroutine 1307-1310, 1408, 1409, 1413- 1416, 1604, 1605, 1606, 1704-1707ST2000 front-end system 1405 Counter 1406 “Wait event” 1412 SS7 userlayer 1501, 1701 TCAP layer 1502, 1702 SCCP layer 1503, 1703, 1607 MTPlayer 1504, 1505, 1506, 1608, 1609 Online simulator 405, 1901

What is claimed is:
 1. A simulator for simulating an intelligent network, the intelligent network including at least one service switching point to which a call having an intelligent network specific telephone number is switched, a service control point which provides the at least one service switching point with information on how to process the call, and a signal system no. 7 (SS7) handling dialog between the at least one service switching point and the service control point, the simulator comprising: a traffic simulator generating intelligent network event sequences according to rules of traffic theory; a service control point simulator providing event-oriented simulation of the service control point using first process models; a first arrangement for exchanging data between the traffic simulator and the service control point simulator; and a second arrangement for entering and storing network configuration, a communication service specification and simulation parameters, the second arrangement transferring data from the network configuration, communication service specification and the simulation parameters to at least one of the traffic simulator and the service control point simulator.
 2. The simulator according to claim 1, further comprising: an SS7 simulator providing event-oriented simulation of the SS7 as a function of at least one of: i) a second process model, and ii) a constant delay time.
 3. The simulator according to claim 2, wherein the SS7 simulator simulates the at least one service switching point, signal relay point components, and a link to the service control point using process models, the SS7 simulator further simulating SS7 signaling channels between the at least one service switching point, the signal relay point components, and the service control point using the constant delay time.
 4. The simulator according to claim 2, further comprising: an overload protection simulator simulating overprotection mechanisms, the overload protection simulator simulating a number of events processed by at least one of the traffic simulator, the service control point simulator and the SS7 simulator, as a function of a load on at least one of the traffic simulator, the service control point simulator and the SS7 simulator.
 5. The simulator according to claim 4, wherein the overprotection simulator simulates the number events processed as a function of queue length and as a function of user-definable parameters.
 6. The simulator according to claim 4, wherein the overload protection simulator controls a volume of events one of generated and forwarded by the traffic simulator as a function of a load on the service control point simulator.
 7. The simulator according to claim 4, further including user definable parameters for establishing at least one of the network configuration and the communication service specification, the user definable parameters being entered via a user interface and being stored in at least one configuration file, the user definable parameters being transferred to at least one of the traffic simulator, service control point simulation, the SS7 simulation and the overload protection simulator at a beginning of simulation; wherein, for the SS7 simulator, the user definable parameters include at least one of: a count of the at least one service switching point, a number of signaling channels between a signal relay point and one of the service control point and the at least one service switching point, delays between the signal relay point and at least one the service control point at the at least one service switching point, at least one of a type and a number of processors used in layers of the SS7, processes and process times running on the processors used in the layers of the SS7, and delays between the processes running on the processors used in the layers of the SS7; wherein, for the service control point simulator, the user definable parameters include at least one of: at least one of a type and a number of processors in the service control point, a type of assignment between and a processor of the service control point, at least one of a type, duration and priority of processes running in the service control point, a type of conversion from an intelligent network event to a service control point sequence, and a number of process incarnations per processor in the service control point; wherein, for the traffic simulator, the user definable parameters include at least one of general parameters, service-specific parameters and parameters for a televoting service per selection option, the general parameters including at least one of: a time until timeout, a rerouting delay time, a number of lines to/from the at least one service switching point, a follow-up call probability, a maximum number of follow-up calls, an average/maximum recorded announcement duration, a number of attendant consoles, the service-specific parameters including at least one of: at least one of an average call and recorded announcement duration, a maximum recorded announcement duration, a number of attendant consoles, a recorded announcement probability, a rerouting probability, and a number of lines, the parameters for the televoting service per selection including at least one of: a start time, an end time for follow-up calls, a destination value, and a number of destination values; and wherein, for the overload protection simulation, the user definable parameters include at least one of: a critical service control point queue, a critical service control point utilization, and a duration of call protection at the at least one service switching point.
 8. The simulator according to claim 7, wherein the SS7 layers include at least one of MTP1, MTP2, MTP3, SCCP and TCAP.
 9. The simulator according to claim 1, wherein the traffic simulator generates the intelligent network event sequence as a function of user-definable settings stored in at least one file and transferred to the traffic simulator at a beginning of simulation, the user-definable settings including: information on a variation over time of an average traffic volume in calls per time unit per at least one of: i) intelligent network service, ii) subscriber, and iii) service switching point; information on probabilities relating to a further progress of a call after receiving a processing information message from the service control point, including at least one of: i) at least one of an average call duration and a recorded announcement duration, after a call is successfully switched, and ii) probabilities of unsuccessful switching; and information on probabilities related to a further progress of a call prior to receiving a processing information message from the service control point, including at least one of a timeout and caller hang ups; wherein the intelligent network event sequences are generated by generating a first event for each simulation interval per at least one of: i) intelligent network service, ii) subscriber, and iii) service switching point, assuming a Poisson distribution, and as a function of the instantaneous average traffic volume, and by entering the first event in an event calendar as a function of generation time; wherein follow-up events are assigned to the first event as a function of service control point parameters, and are entered into the event calendar as a function of generation time; and wherein the event calendar contains all first and follow-up events in chronological order.
 10. The simulator according to claim 1, wherein time stamps are logged for each first event of the intelligent network event sequences generated by the traffic simulator upon passing through the simulator, the time stamps including a time stamp t1 corresponding to a time at which a message corresponding to each first event is generated in the at least one service switching point, and a time stamp t4 after each first event is processed by the service control point simulator.
 11. The simulator according to claim 10, wherein the first event is a call.
 12. The simulator according to claim 2, wherein time stamps are logged for each first event of the intelligent network event sequences generated by the traffic simulator upon passing through the simulator, the time stamps including a time stamp t1 corresponding to a time at which a message corresponding to each first event is generated in the at least one service switching point, a time stamp t2, after each first event from the traffic simulator is processed by the SS7 simulator, a time stamp t3 after a message from the SS7 simulator corresponding to each first event is processed by the service control point simulator, and a time stamp t4 after a message from the service control point simulator corresponding to each first event is processed by the SS7 simulator.
 13. The simulator according to claim 1, further comprising: a first transfer file storing the intelligent network event sequences generated by the traffic simulator, the first transfer file being transferred to and processed by the service control point simulator, with time t1 being stored for each event in the intelligent network event sequences, t1 corresponding to a time at which a message is generated in the at least one service switching point; and a second transfer file storing events processed by the service control point simulator, the second transfer file being transferred to the traffic simulator, with time t4 being stored for each of the events processed by the service control point simulator, t4 corresponding to a time at which a follow-up message is generated in service control point and a time at which the follow-up message arrived in the at least one service switching point.
 14. The simulator according to claim 2, further comprising: a first transfer file storing the intelligent network event sequences generated by the traffic simulator, a time t1 corresponding to a time at which a message is generated in the at least one service switching point being stored for each event in the intelligent network event sequences, the first transfer file being transferred to and processed by the SS7 simulator; a second transfer file storing events processed by the SS7, a processing time t2 corresponding to a time at which a message arrives in the service control point being stored for each of the events processed by the SS7, the second transfer file being transferred to the service control point simulator; a third transfer file storing events processed by the service control point simulator, a time t3 corresponding to a time at which a follow-up message is generated in the at least one service control point being stored for each of the events processed by the service control point simulator, the third transfer file being transferred to the SS7 simulator; and a fourth transfer file storing the events processed by the SS7 simulator, a time t4 corresponding to a time at which a message arrives in the at least one service switch point being stored for each of the events processed by the SS7 simulator, the fourth transfer file being transferred to the traffic simulator.
 15. The simulator according to claim 13, wherein the intelligent network sequences generated by the traffic simulator are entered in the first transfer file and the events processed by the service control point simulator are entered in the second transfer file, and are transferred to the service control point simulator and the traffic simulator, respectively, multiple times in sequence, at least one of a constant service control point delay time and an SS7 delay time being assumed in a first pass of the transfer of the first transfer file to the service control point simulator for generating follow-up events by the traffic simulator, the delay times being modified in subsequent cycles as a function of response times determined as a function of the second transfer file after passing though the service control point simulator.
 16. The simulator according to claim 1, further comprising: a first local event calendar assigned to traffic simulator in which events to be processed by the traffic simulator are entered.
 17. The simulator according to claim 16, further comprising: a second local event calendar assigned to the SS7 simulator in which events to be processed by the SS7 simulator are entered as a function of one of: i) time stamps of the events to be processed by the SS7 simulator, and ii) priorities of the events to be processed by the SS7 simulator.
 18. The simulator according to claim 17, further comprising: a third local event calendar assigned to the service control point simulator in which events to be processed by the service control point simulator are entered as a function of i) time stamps of the events to be processed by the service control point simulator, and ii) priorities of the events to be processed by the service control point simulator.
 19. The simulator according to 16, wherein the local event calendar has multiple nested queues, each of the queues including events to be processed by one sub-component of the traffic simulator.
 20. The simulator according to claim 18, further comprising: a global event calendar including events corresponding to messages between the service switching point and the service control point, and reference to at least one of: i) the first local event calender of the traffic simulator, ii) the second local event calendar of the SS7 simulator, and iii) the third local event calendar of the service control point simulator in the form of a shared queue, the events being entered in the global event calendar as a function of at least one of time and priority.
 21. The simulator according to claim 20, wherein randomly-generated call-independent events are stored in the global event calendar and processed by one of traffic simulator, the SS7 simulator and the service control point simulator, to take into account call-independent processes within network components.
 22. The simulator according to claim 21, wherein the call-independent events includes operating system interventions within processors of the service control point.
 23. The simulator according to claim 20, further comprising: a simulation clock assigned to each of the traffic simulator, the SS7 simulator and the service control point simulator, the simulation clock stopping during processing of an event from at least one of the global event calendar, the first local event calendar, the second local event calendar, and the third local event calendar, wherein at the end of the processing, the simulation clock is moved forward to a time of the next event entered in the at least one of the global event calendar, the first local event calendar, the second local event calendar and the third local event calendar.
 24. The simulator according to claim 20, further comprising: at least one internal user-definable event assigned to one of an external message and an external event, the at least one internal user-definable event being entered in at least one of the first local event calendar, the second local event calendar and the third local event calendar, each at least one internal user-definable event having a predetermined duration.
 25. The simulator according to claim 24, further comprising: an internal event entered in the global event calendar, the simulation module being invoked by the internal event, the internal event referring to at least one of the first local event calendar, the second local event calendar and the third local event calendar for processing a next internal event; and an internal simulation clock, the internal simulation clock being reset after processing the internal event; wherein, if a further event belonging to a process chain is provided, a reference to the further event is entered in the global event calendar along with a first instantaneous internal simulation time; and wherein, if an event currently being processes is a last event in a process chain, an external event is generated by the simulation module and entered in the global event calendar along with a second instantaneous internal simulation time.
 26. The simulator according to claim 1, wherein the traffic simulator simulates ordinary telephone traffic.
 27. The simulator according to claim 2, further comprising: an output file storing at least one network quantity with a corresponding simulation time, the at least one network quantity including at least one of: i) a number of calls generated by the traffic simulator and arriving at the intelligent network per time unit, ii) a number of messages being processed by the SS7 simulator that are destined for the service control point simulator, iii) a number of message in the service control point simulator and iv) a number of messages being processed by the SS7 simulator that are destined for the traffic simulator.
 28. The simulator according to claim 1, further comprising: an output file, the service control point simulator storing statistical quantities and corresponding simulation times in the output at one of regular intervals and presettable simulation times, the statistical quantities including at least one of CPU utilization, queue length, number of processes executed per time unit, the statistical quantities being at least one of: i) separated by CPU number, ii) averaged over all CPUs, and iii) separated by minimum and maximum values of a CPU.
 29. The simulator according to claim 1, further comprising: a file, service switching point-specific number of occupied lines at least one of: i) to an exchange, and ii) in the intelligent network, being logged to the file at one of: i) regular intervals, and ii) at presettable simulation times.
 30. The simulator according to claim 1, further comprising: a user interface used as an input element for generating a simulation by entering simulation parameters, the user interface managing configuration files and displaying simulation results in graphical form.
 31. The simulator according to claim 1, further comprising: an event-oriented simulator of additional network components, the additional components including at least one of a service management system and an intelligent peripheral. 